arXiv:1501.03593vl [cs.CR] 15 Jan 2015 


Privacy by Design: On the Conformance 
Between Protocols and Architectures* 


Vinh-Thong Ta and Thibaud Antignac 

INRIA, University of Lyon, France 
{ vinh-thong. ta, thibaud .antignac} @inria. fr 


Abstract. In systems design, we generally distinguish the architecture 
and the protocol levels. In the context of privacy by design, in the first 
case, we talk about privacy architectures, which define the privacy goals 
and the main features of the system at high level. In the latter case, we 
consider the underlying concrete protocols and privacy enhancing tech¬ 
nologies that implement the architectures. In this paper, we address the 
question that whether a given protocol conforms to a privacy architecture 
and provide the answer based on formal methods. We propose a process 
algebra variant to define protocols and reason about privacy properties, 
as well as a mapping procedure from protocols to architectures that are 
defined in a high-level architecture language. 


1 Introduction 

According to the definition provided in [^, “the architecture of a system is the 
set of [elements and their relations] needed to reason about the system”. In the 
context of privacy, the elements are typically the privacy enhancing technologies 
(PETs) themselves and the purpose of the architecture is to combine them to 
achieve the privacy requirements. Generally speaking, an architecture can be 
seen as the abstraction of a system since an architecture abstracts away the de¬ 
tails provided by PETs (such as message ordering, timing, complex cryptographic 
algorithms, etc.). Architectures only capture the main functionalities that a sys¬ 
tem should provide, for instance, which computations and communications are 
to be performed by the components. 

Works in privacy by design mainly focus on PETs rather than architectures. 
In the position paper [3] , the authors addressed the problem of privacy by design 
at the architecture level and proposed the application of formal methods that 
facilitate a systematic architecture design. In particular, they provided the idea of 
the architecture language and logic, a dedicated variant of epistemic logics m , to 
deal with different aspects of privacy. Basically, an architecture is defined as a set 
of architecture relations, which capture the computations and communications 
abilities of each component. For instance, a relation computei{x = t) specifies 
that a component i can compute a value t for x. Nevertheless, since [3] is a 
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position paper, the language envisioned in the paper is mainly based on an 
introductory description. An extended version of this language is detailed in [2]. 

In this paper, we address the major question that whether the integration 
or combination of several different PETs conforms to a particular architecture. 
One challenge we have to face is that due to the diversity of technologies and 
protocols, their combination can raise a huge number of scenarios. Moreover, 
architectures are defined in an abstract way, while concrete implementations are 
more detailed, and it is challenging to define a proper abstraction from a lower 
to a higher level. The goal of this paper is to provide answers to this question. 

Specifically, our main contributions are two-fold: first, we propose a modi¬ 
fied variant of the applied 7r-calculus m for specifying the protocols related to 
PETs, and reasoning about the knowledge of components during the protocol 
run. Second, we propose a mapping procedure which defines the connection be¬ 
tween the protocol specified in the calculus and the architecture defined in the 
architecture language. This mapping allows us to show whether a protocol (or a 
combination of protocols) conforms to a given architecture. To the best of our 
knowledge, this work is the first attempt that examines the connection between 
the two levels based on formal methods in the context of privacy protection. 

The paper is organized as follows: in Section we review the privacy ar¬ 
chitectures language (PAL) proposed in |2], which is a high-level language for 
specifying architectures and reasoning about privacy requirements in them. Sec- 
tionsl^andfflcontain our contributions. The modified applied 7r-calculus is given 
in Section Section discusses the connection between each calculus process 
and relation in PAL, as well as the definitions and properties of the conformance 
between the two levels. In Section |5] we review the most relevant related works. 
Finally, we conclude the paper and discuss about the future works in Section 


2 Architecture Level 

The language we review here is a simplified version of the one in [2]. The func¬ 
tionality of a service is defined byf7={A = T}, where T is a term and X G Var 
represents a variable that can be either indexed {Xk) or unindexed (A). Each 
X can be a single variable or an array of variables. F G Fun denotes a function, 
and QF{X) defines the iterative application of F to the variables in the array 
X (e.g.: © -|- (A) defines the summation of the variables in a given array). 

T ::= A I F{Ti, ...,©„) | © E(A); A ::= A | Ak 

A ::= {7^} 

7^ ::= (a) | Receive,j {{Att},X) \ Computei {X = T) 

I Chech = T 2 ) I \ TrusU,, 

Att::= Attesti ({A = T}^ 

An architecture A is defined by a set of components Ci, i h [1,..., n], associ¬ 
ated with the set of relations {TZ}. Each relation TZ specifies a capability of the 
components. Subscripts i and j denote component IDs. {X) expresses 


the fact that X is a variable that component Ci initially has (i.e., an input 
variable of Ci). Receiveij{{Att}, X) expresses the possibility for Q to receive 
the variable X directly from Cj, and optionally an attestation Att related to 
this variable. An attestation, defined by Attesti{{X = T}), captures a statement 
made by Ci on the set of equations. Each X = T in the set {X=T} expresses 
the integrity of X, stating that it equals to T. Computei{X = T) says that Ci 
can compute a variable defined by an equation X = T. Checki (Ti = T 2 ) states 
that Ci can check the satisfaction of property Ti = T2. The property X = T in 
Attesti is related to the same property in ComputCi, namely when Ci computes 
A = T it can send an attestation on this. Veriff**'^‘^*{Att) says that Cj is able to 
successfully verify the origin of an attestation. Finally, Trustij is used to express 
the fact that component Ci trusts Cj, and this trust relation does not change 
during operations. Trust relations are pre-defined, and an attestation sent by Ci 
will be accepted by Cj after a successful verification only if Cj trusts Ci. 

The semantics of an architecture is defined as its sets of compatible traces. A 
trace is a sequence of possible high-level events occurring in the system. Events 
can be seen as instantiated relations of the architecture. 

6 ::= Seq{e) 

e :;= has, [X'.V) \ receivcij {{Att},X : E) | compute^ [X = T) 

I Chech (Ti = Ta) I [Att) 

To distinguish events from relations, we let events start with lowercase. For 
instance, event hasi [X : V) captures the fact that Ci has the value V for X, 
and computei (A = T') expresses the fact that Ci performes the computation 
X = T. The other events are interpreted based on their corresponding relations 
(see [2] for details). An event trace 9 is compatible with an architecture A, if in 
this trace, only events which are instantiations of components of the architecture 
can appear in 0 - except for the compute events. For the case of compute events, 
besides the computation specified explicitly in the architecture, we also take into 
account the “background” computations (deduction) that can be performed by 
each component, based on the data it has. This deduction ability of each Ci is 
captured by its deduction system [>i [2] . The semantics of events is based on the 
component states and the global state of the architecture, given as follows: 

State = Statev x Statep-, 

Statev= [Var —>• Valp)', Statep = |{A = T} U {Ti = T 2 } U {Trustij}^ 

The state of a component [State) is composed of a variable state [Statev) 
and a property state [Statep). Statev assigns a value (which can be undefined, 
T) to each variable. Statep defines the set of properties X = T and Ti = T2 
known by a component. 

In the sequel, cr is used to denote the global state of the architecture A (state 
of the components (Ci,..., C„)) defined on State^. ai [ai = (cr)', erf*)) denotes 
the state of the component Cj, where erf and erf* represent the variable state 
and property state of Ci, respectively. The initial state of A, denoted by Init^, 
contains only the trust properties specified by the architecture. The semantics 
of an event trace is defined by the function Sp, which specifies the impact of 


a trace of events on the states of the components, through the impact of each 
event on the states (defined by the function Se)- 

St ■ Trace x State" —> State"\ Se ■ Event x State" —>■ State"', 

St (e-O, cr) = St^O, Se^c, ct)); St ((), a) = cr; 

Se {computei [X = T),a)= a[{(j"i[evaHT,a"i) / X\, af U {X = T}) / a; ]. 

Due to lack of space we only present Se for the compute event here, the full 
list can be found in [5]. The notation e.6 is used to denote a trace whose first 
element is e and the rest of the trace is 6, while () denotes the empty trace. Each 
event modifies only the state ai of the component Ci . A modification is expressed 
by a[{v,pk)/ai] that replaces a" and crf^ of Ui by v and pk, respectively. The 
effect of compute^{X = T) is to set X to the evaluation of T based on the current 
variable state a", which is denoted by eval(T,a"). Event computci also results 
in adding the knowledge about X = T to the property state trf^. 

The semantics of an architecture A is defined as 5(A) — {a G State" \ 36 G 
T{A) such that St{6, Init^) = a}, where T{A) is the set of compatible traces of 
A. To reason about the privacy requirements of architectures, the architecture 
logic is proposed in [5], which is based on the architecture language PAL. 

(f) ::= Hasf (x) | Has^"" (x) | X (Ti = T 2 ) | </>i A 02 

This logic involves modality Ki that represents the epistemic knowledge m 
of Ci about Ti = T 2 . In the rest of the paper, we refer to 0 as an architecture 
property. The semantics 5(0) of a property 0 is defined as follows: 

lag S{Hasf (x)) 44- 3 a G 5(A), a^X) / T 

2. A G SiHasr"" (X)) V a G 5(A), a”(X) = T 

3. A G S{Ki (Eg)) 44 V a' G 50A), 3 a G 50A), 3 Eg': (cr >, cr') A (erf Eg') 

A {Eg' =4 Eg), 

where Eq {Eq') represents an equation Ti = T 2 {T[ = T!^). An architecture 
satisfies the Hasf‘^{X) property if and only if Ci may obtain the value of all 
Xfc in Range{X) in at least one compatible execution trace. Has"°"^{X) holds 
if and only if no execution trace can lead to a state in which Ci gets any value 
of any X^. We note that Hasi properties only inform on the fact that Ci can 
get or derive some values for the variables but they do not bring any guarantee 
about the correctness of these values. Integrity requirements can be expressed 
using the property Ki{Ti = T 2 ), which states that the component Ci knows the 
truth of the integrity property Ti — In cr > a', compared to a', a represents 
the state at the end of a longer trace. Finally, trf Eq and Eq ^ Eq capture 
that Eq' can be deduced from af’'' and Eq , respectively. 

Example Architecture: Let us consider a very simple smart metering ar¬ 
chitecture which consists in the communication between two components: the 
meter (M) and the operator (O). The goal of this architecture is to ensure that 
the operator will get the consumption fee for a given period and to be convinced 
that the fee is correct. The privacy requirement says that O must not obtain the 
consumption data. One possible design solution is that the meter passes directly 
the consumption data to the operator who will compute the fee: 


= {for i G [1, ..., r]: ComputeM{Xm, = 

Receiveo,M{AttestM{Xmi = Xc^), Xrm); [AttestM{Xmi = 

ComputeoiXtf^ = Computeo{Xfee = 0 + [Xtf)), Trusto,M}- 

In the architecture Ai, the meter initially has the (input) variable Xc that 
represents the array of r consumption data Xci, i G [1, r]. The meter is 

capable to compute each metered data {Xmi) based on each consumption data 
(XcJ. Intuitively, in X^^. = X^., will get the value of X^^ ■ Then, the 
operator will receive the metered data (X^J, along with the attestation made by 
M on the integrity property X^, = X^ ■ After verifying the received attestation 
with success, due to Trusto,M the operator knows that X^^ = Xc-. Then for 
each Xrrii, O computes the tariff based on the function F. Finally, O computes 
the summation of the r tariffs (i.e., array Xtf) to get the fee for the period. 
The requirements of the architecture are modeled with the properties of the 
architecture logic. Namely, Hqsq^ i^fee) specifies that O has (all) the fee, while 
(Ac) says that O must not have any consumption data. Ai fulfills the 
first requirement, but it does not satisfy the privacy requirement because based 
on Receiveo,M{AttestM{Xmi = Xc- ), X,^J O can obtain X^.^ from X^.. 

3 Protocol Level 

To reason about the concrete implementations of an architecture, we propose 
a modified variant of the applied 7r-calculus. We decided to modify the basic 
applied 7r-calculus |13j because thanks to its expressive syntax and semantics, it 
is broadly used for security verification of systems and protocols (e.g., [m, m, 
[m, m. i, 0, m)- Our main goal is to modify some syntax and semantics 
elements of the applied 7r-calculus, making it more convenient to find the con¬ 
nection between the calculus semantics and the interpretation of architecture 
relations. One of such modifications is the notion of component, which is char¬ 
acterized by three elements: (i) the internal behavior of the component; (ii) the 
unique ID assigned to the component; and (iii) the set of IDs of the components 
who are trusted by this component. Another reason why we cannot use the basic 
applied 7r-calculus is that it focuses on reasoning about the information a Dolev- 
Yao attacker (who can eavesdrop on all communications) obtains. However, in 
our case we reason about the information that components can have, which are 
only aware of the communications they can take part in. 

3.1 Syntax of the Modified Applied 7r-Calculus 

We assume an infinite set of names Af and variables V, and a finite set of 
component identifiers C, where V n Af H £ = 0. Terms are defined as follows: 

t ::= c \ k \ n,m,k \ x,y,z \ f{ti,...,tp)- 

The meaning of each term is given as follows: c models a communication chan¬ 
nel. li represents a component ID (£ yf Ij if i yf j) that uniquely identifies a 


component, n, m and k denote names, which model some kind of data (e.g., 
a random nonce, a secret key, etc.). Terms x, y, z denote variables that repre¬ 
sent any term, namely, any term can be bounded to variables, /(ti ,... ,tp) is a 
function, which models cryptographic primitives, e.g., digital signature can be 
modeled by sign{xm, Xsk), where Xm and Xsk specify the message and the private 
key, respectively. Moreover, / can also be used to specify verification functions 
(e.g., the signature check is modeled by function checksign(sign{xm, Xsk), Xpk), 
where Xpk represents the public key corresponding to the private key Xgk)- 

We rely on the same type system for terms as in the applied 7r-calculus [T^ . 
Due to lack of space, we omit the unimportant details of this type system, and 
leave it implicit in the rest of the paper. We assume that terms are well-typed 
and that substitutions preserve types (see [22] for details). 

The internal operation of components is modeled by processes. Processes are 
specified with the following syntax: 

P,Q,R::= c{t).P II c{tm,taig))-P || c{x) .Q II c{x,n,Xsig).Q || P\Q 
II un.P II let X = t in P || if (ti = t 2 ) then P || 0. 

Note that for simplicity we left out the infinite replication of processes, IP. 
As a result a protocol/system run consists of a finite number of traces. 

Process c{t).P sends the term t (where t fy (tm, fyig)) on channel c, and 
continues with the execution of P. Process c{tm,tsig).P models the attestation 
sending, where and the signature tsig are sent on c. 

Process c{x).Q waits for a term on channel c and then binds the received 
term to x in Q. Process c{xm, Xsig).Q waits for a term Xm and its signature Xgig 
on channel c, which models the attestation reception. 

P\Q behaves as processes P and Q running (independently) in parallel. A 
restriction vn.P is a process that creates a new, bound name n, and then behaves 
as P. The name n is called bound because it is available only to P. Process let 
X = t in P proceeds to P and binds every (free occurrence of) x in P to t. 

Process if {ti = t 2 ) then P says that if fy = t 2 (with respect to the equational 
theory E, discussed later) then process P is executed, else it stops. Its special 
case is if Xm = checksign{xsig, xf^) then P, which captures the verification of an 
attestation (i.e., signature Xsig with key xf^). For message authentication and 
integrity protection purposes digital signature and message authentication code 
(MAC) are used. In this paper we only consider signature. 

Finally, the nil process 0 does nothing and specifies process termination. 

Components: To make the connection between calculus processes and archi¬ 
tecture relations more straightforward, we introduce the notion of components. 
lP\i defines a component with the unique identifier I, who trusts the compo¬ 
nents whose IDs are in the set p, and whose behavior is defined by process P. 
The trust relation can be either one-way or symmetric, for instance, 

and represent components h and I 2 who trust each other. The rationale 

behind this way of component specification is that the component IDs and the 
trust relation between them are pre-defined, and do not change during the pro- 


tocol run (this is what we assumed at the architecture level). In addition, we 
assume that a trusted component will not become untrusted. 

Systems: A system, denoted by S, can be an empty system with no compo¬ 
nent: O5; a singleton system with one component: the parallel composition 

of components: I where pi and p2 may include I2 and h, respec¬ 

tively; or a system with name restriction. To capture more complex systems, we 
also allow systems to be the parallel composition of sub-systems, | 82 - 

S-.-.= Os I I i^n.s I ( 5 i I ^2). 

The name restriction vn.S represents the creation of new name n, such as secret 
keys, or a random nonce which are only available to the components in S. 

3.2 Semantics of the Modified Applied 7r-Calculus 

In order to check the conformance between protocols and architectures, it suffices 
to consider the internal reduction rules of the calculus, which model the behavior 
of the protocol (without contact with its environment). Reduction rules capture 
the internal operations (e.g., let or if processes) and communications performed 
by components. We define and distinguish the following reduction rules: 

(Reduction rules) 

(Rev) \c{t).P\ 1 i \yc{x).Q\‘’f_ \_p^Pi \ {tm,tsig)-, 

n- reVn-ff (l-i ,Xm ■tm) 

(ReVatt) [c{tm,tsig).P\i‘ \ [c{Xm, X sig)-Q -> 

L-PJfl I [_Q{tm,/Xm,tsig/Xsig}\i^ 

(Verifatt) [if Xm = checksign{xsig,t^^) then Q' m) 

where {tm/xm, tsig/xsig}- Note: Ij accepts the attestation if k £ pj. 

(Check) [if (ti = t2) then [P\r (^1 = ^2 £ A, t2 7^ eheeksign)-, 

(Comp) [let x = t in Pjfj' [P{t/x}\i^, (t = x' or /, such that 

ijJcomp = eomp{lj, X : t) when / ^ {sign, eheeksign}, else ujeomp = r); 

r, ■ has(l^ ,x:k) n ■ 

(Has) (nk.) [let x = k in P\i^, [vk.) [P{k/x}\f, , 

(Error) [*/(^1 = ^2) then Pff_ (*/ ti = t2 ^ P); 

(Par-c) ^ then LQI pj;;; ^ 

(Res-C) [P\i^ [P'\n then [p'n.P}'^^ [nn.P', where 

tjJc £ {eomp{lj, X : t), has{lj, x : k), cheekllj, t\ : t2), error, veratt{lj, Xm-tm)} 

(Par-S) Si S'l then ^ | ^ S2 \ Sf, 



(Res-S) S S' then vn.S un.S', where 

ujs can be ujc, and rcv{lj, h, x : t), rcvattilj, k, Xm ■ tm)- 

Before defining the system states, we label each reduction relation (arrow) based 
on the name of the rule and the terms used in them. We adopt the notion of 
equational theory E from m. m. which contains rules of form ti = t 2 & E, 
that define when two terms are equal. For instance, the equational theory E may 
include rules for signature verification, decryption, MAC verification, etc. The 
meaning of each reduction rule is as follows: 

— Rule (Rev) captures the communication between components U and Ij. Namely, 
li sends value t for x on channel c, which is received by Ij. As a result, we 
get Q{t/x} that binds t to every free occurrence of a: in Q. It is assumed 
that t ^ {tm, tsig), which is treated as a special case. 

— Rule (Revait) deals with exchanging the message tm and the signature tgig 
on channel c, which models the reception of the attestation Attesti. {{xm = 
tm})- As a result, we get Q in which tm and the signature are bound to Xm 
and Xsig, respectively. The reason that we distiguish (Revatt) from (Rev) is 
because we want to make a clear distinction between the cases of receiving 
a message with and without an attestation. 

— Rule (Verifatt) captures the case when after binding tm and tsig to Xm and the 
signature Xsig, respectively, component Ij successfully verified the signature 
using the corresponding public key of li, tf^. We implicitly assume that tm 
and tsig contain enough information for the receiver to identify the “type” of 
the received message (e.g., the consumption fee in smart metering systems). 
Rules (Revatt) and (Verifatt) together specify the scenario when k sends to 
Ij the value tm for Xm, with the signature that proves the integrity and the 
authenticity of this message. Then, in case Ij trusts li, it knows the truth 
about the integrity property Xm = tm- 

— Rule (Check) considers the case when two terms are equal in the check (with 
respect to the equational theory E), which leads to P as result. We assume 
that t 2 is not the checksign function, which is used for the attest verification. 

— Rule (Comp) models the computation x = t performed by Ij. As a result, 
every free occurrence of a; in P is given the value t. In this rule we assume 
that t can be either a variable or a function (except for sign and checksign, 
because they are considered as parts of the attestation), but not a name. 

— Rule (Has) deals with the case when t is a name. The name k, either bound 
(with i/k) or free (without vk), represents the value of x. Here x is used to 
model the variable that Ij initially has to capture the input data coming 
from the environment (e.g., the consumption data in the smart metering). 

— Rule (Error) specifies the case when two terms are not equal with respect to 
E. As a. result, the process will continue with the nil process. 

— Rules (Par-C) and (Res-C) say that the if and let reductions are closed 
under parallel composition and restriction within a component, respectively. 
Rules (Par-S) and (Res-S) capture that all the reductions are closed under 
parallel composition and restriction on systems, respectively. 


to <jJ 

Instead of referring to the trace of reductions —^ we will refer to the 

trace of the corresponding labels w], ..., w™ for the sake of clarity. 

States of components and systems: Let us consider a system S with n 
components. Let Labels be the set of all labels {cOg € Labels) of the reduction 
relations defined above, and let LTraces be the set of all possible label traces 
of S. We define the functions Vst, Vt and Vl that update the states of the 
components and the entire system. Vt and Vl are similar to St and in PAL, 
but they are based on label traces and labels instead of traces of events and 
events. Vst takes as input the set of all the possible label traces of S and handle 
each trace with Vt- Let State^ denote the set of global state of S and 0*^ an 
empty set of traces. Finally, in tOg-tr the label uig is the prefix of the trace tr. 

Vst ■ {LTraces} x State's —>■ State's', 

Vt '■ LTraces x State'^ —>■ State'^-, Vl '■ Labels x State's —>■ State's', 

VsT^LTraces, A) = Vst {LTraces\{tr}, VT^tr, A)); VsT(0tr, A) = A; 

VTiojs-tr, A) = VT{tr, Veiojg, A)); Vt ((), A) = A; 

VL{has{li,x : k). A) = \[{\'l.{k/x}, / Ai]; 

VL{rcv{li,lj,x '. t),\) = \[{\'l^{t/x}, / Ai] 

VL{rCVattili,lj,Xm '■ tm), A) = A[(A”. {tm/Xm}, Af*") / AiJ 
VL{comp{li,x : t). A) = A[(A”.{A]'.t/a:}, U [x = t}) / AjJ 
VL{check{li,ti : t2). A) = A[(Ar., U [tl = ta}) / A,J if X^ti = X^ti € E 
VLiverattili, Xm '■ tm), A) = A[(A]i, Xf^ U {{Xm = tm} if Trusti-^i- £ Xf^}) / Aij. 

We let Xi- and A denote the state of component h and the global state that 
consists in the state of all components in the system, respectively. Each Xi. is 
defined by the pair (A“, A^.^), which is the variable state and the property state 
for component h, respectively. In our calculus the variable state A“ is defined by 
the set of substitutions ..., tm/xm}, which captures the terms available 

to li, as well as the values of each variable from the perspective of k. X^t/x} 
is a shorthand for {X}. U {t/x}) \ {t'/x}, if {f/x} G A", for some t'. Af^ is the 
set of integrity properties (e.g., ti = ^ 2 ) that captures the knowledge gained by 
Ij about these properties. X}t represents the evaluation of t based on A", and 
AJ'.fi = X},t 2 G E says that the evaluation of ti and t 2 in X}, are equal up to the 
equational theory E. We also consider the state update that results after a failed 
check (namely, \[XErrl\], where Xett denotes the error state), though we omit 
the formal details here to save space. 

4 From Protocols to Architectures 

In the sequel, we discuss how the corresponding architecture can be extracted 
based on a given protocol or system. Namely, given a protocol specified in our 
process calculus we define an extraction procedure that extracts the correspond¬ 
ing architecture relations. The extraction procedure is based on the application 
of a set of extraction rules that we define below. Each extraction rule specifies 
the connection between the traces of labels of a system and the corresponding ar¬ 
chitecture relation. We assume a (initial) system S which consists in the parallel 



def 

composition of r components (for a finite r), namely, ^ I I 

The corresponding architecture relations will be extracted based on the possible 
traces (i.e., the trace semantics) of S. We emphasize that during the extraction 
of architectural properties we only consider the reduction traces to capture the 
communication between components, without considering the activity of the en¬ 
vironment (i.e., the Dolev-Yao attacker). Formally, we do not take into account 
the labelled transitions known in the applied 7r-calculus m- The reason is that 
the architecture relations focus only on the abilities of the components and the 
communication between them. 

An architecture does not not contain the Compute relations for background 
computations. The situation is similar at the protocol level, where the protocol 
description specifies the basic computations and communications of the compo¬ 
nents, without involving the background computations. Hence, when extracting 
the architecture relations, it is sufficient to consider only the protocol description 
and its corresponding reduction traces. The background computations will be 
taken into account when we discuss the mapping to the Hasj architecture logic 
property for reasoning about the data that can be deduced by a component. 

Given a system S and the set LTraces of (all) its possible label traces, we 
define the extraction function Xt that extracts the corresponding architecture 
based on LTraces- ^ST is interpreted similarly as Vst- Rds denotes the set of 
architectural relations of S. Function Xs extracts a relation based on a label lOs 
and put it into og. We use og to denote the set of the extracted relations so far. 

We have the following extraction rules: 

XsT • {hThaceg} x Reis —^ Lists', 

Xt : LTraces x Reis —>■ Reis', 

XsriLTraces, ots) = XsT{LTraces\{tr}, Xr^tr, as))', 

XriuJs-tr, Qg) = Xritr, XsioJs, as))', 

XL[has(lj,x: k), as) = as U {Hasf^’^'^ix)}; 

Rrecv. XL(rcv{lj,li,x '■ t), og) = ag U {Receivei-^i.{x)}', 

R-att • Xs{rCVatt(lj,li,Xm . tm), CoTTipUtei^l^Xjn — tm) ^ Og) — 

Qg U {Receivei.,i^{{Att},Xm)}, where Att = Attesti.{{xm = tm}); 
j^comp, XL{comp{lj,x : t), Qg) = Qg U {Computei-(x = t)}, where t ^ {sign, checksign}-, 
j^check. XL{check{lj,ti '. t2), Qg) = Qg U {Checki-{ti = t2)} if ti = t2 € A; 
j^attver. XsivCr au(lj, Xm '■ tm), [TrUStl-^l^, ReCeivCl - ,l^[{Att}, Xm)} C Qg) = 

Qg U { Ven/^**®'’*(Att)}, where Att = Attest;, ({xm = tm}); 

All the rules above capture the communication and computation abilities 
of each component during the protocol run and are defined based on the trace 
semantics. In contrast, the Trusti.g^ relations are extracted based on the syntax. 
The initial set of relations is = {Trusti.g. if Ij G pi | V k, Ij G {li,..., A}}- 
The meaning of each rule is defined as follows: 

— Rule corresponds to the relation Has1'^‘^^{x), which says that Ij initially 
has a value for x. The name k represents an input data for x of Ij. 

— extracts the relation Receivei.g.{x), and describes the case when Ij 
receives a value t for x during the protocol run. S' and S" represent the 
systems before and after the communication between li and Ij. S' involves 
the possibility for Ij to receive the variable x. 


Xl '■ Labels x Reis Reis; 
XsT{0tr, Qg) = Qg; 

Xt {{), Qg) = Qg; 


— Rati'’ extracts the relation Receivei-^i^{Attesti-{{Xm = ^m}), Xm), where {xm 
= tm} contains x^ = along with all the equations Xg = Xh computed 
by li in order to constitute Intuitively, besides attesting Xm = tm, h 
attests the integrity of all the computations it performed in order to get 
Xm- S' includes the possibility for Ij to receive Xm, and its signature Xsig- 
Assumption Computei.{xm = ^m) € os captures the fact that k is able to 
compute Xm = tm, hence, it can make an attestation on this equation. 

— Rule corresponds to the relation Compute, for the equations x = f or 

X = x'. We do not extract the computations for signature and its verification 
since these computations are integrated within the Attest relation. 

— Rule extracts the relation Check. To be able to check an equation, 

a component must have the ability to perform the function required in the 
check and it should possess the required data during the protocol run. This is 
determined by the equational theory E, which defines the checking abilities 
of a component. We do not extract Check for signature check because it is 
considered as an attestation verification. 

— Rule deals with the case when component Ij successfully verified 

the attestation sent by component h. However, we get the corresponding 
relation Veriff"'"''{Att) only in case h € Pj (i.e., Ij trusts k). The assumption 
Receivei-j^{Att, Xm) € as captures the fact that Ij has received {Att, Xm)- 

The extraction procedure starts with the initial system S, then we follow the 
possible reduction traces from S and apply the extraction rules where possible. 
Although during the extraction every possible label trace of the system is exam¬ 
ined, due to the simplifications we made on the processes (e.g., infinite process 
replication is leftout), the number of traces is finite, hence, the extraction proce¬ 
dure will terminate. In the sequel, we let As denote the extracted architecture 
of S' (i.e., the set of relations as when we have examined all the possible traces). 

Definition 1 (State based semantics) The state based semantics of a given 
system is defined as V(S) = {A G Statcg \ 3 tr G T(S), Vxitr, Init^) = A}. 

Init^ is the initial state of the system S which contains only the Trust rela¬ 
tions in A^^. We adopt the Has properties used in PAL (Section]^, and define 
their semantics based on the semantics of the calculus. 

ij} ::= Hasif (x) \ Has'f^'"''' (x) | A/. (<i = t 2 ) \ A 4>2 

Definition 2 (Semantics of property if for systems) 

1. S G V(Hast‘‘ (x)) 3 A G V(S).- 3 t' and t such that 

(A“.t' = t) G E, where BoundTo(t) = x 

2. S G V(Hasf°^‘^ (x)) V A G V(S) and'i t G terms(XlJ: 

,3 t' such that (Xifi' = t) G E, where BoundTo(t) = x 

3. S G V(Ki^ (Eq)) 4 V A' G VifiS) 3 A G VifiS), 3 Eq'-. 

(X >i. X') A (Xf^ Eq') A (Eq' Eq). 


S satisfies the property (x) when during the system run, li can deduce 

or obtain a value t for x. (AJ'.t' = t) G E means that k can deduce t based on 
X^.t' and the equational theory E. BoundTo{t) = x captures the fact that this 
t has been bounded to x during the reduction trace (i.e., t is the value of x). S 
satisfies Hasi^^ (x) when li cannot deduce or obtain any value t for x. Finally, 
the deduction \>e Eq and Eq Eq are defined on the deduction system 
based on the equational theory E. 

To compare As and A, we define £, the set of type-preserved mappings from 
terms in the calculus to the terms in PAL: £ = {k i-G i; x i-G X■, f{ti, ..., tm) ^ 
F(Ti, ..., Tm)\ /(xi, ..., Xm) (•)E{X), X = [Xi, ..., Xm]}- It is important 
to emphasize that in each mapping, the result and its preimage must have the 
same type. Defining an explicit type system for terms is not in the scope of 
this paper. Here, we only provide general type matching requirements for the 
mapping rules, giving the reader an intuition about the mapping to understand 
the definitions given below. In £, each ID li can be mapped to an ID i] each 
X can be mapped to a A of the same type, /(ti, ..., tm) can be mapped to 
E{Ti, ..., Tm) if each (tj, Tj) pair has the same type, and the two functions 
return the same type, too. Similarly, /(xi, ..., Xm) can be mapped to ©T(X) 
if they return the same type, and the array X contains m variables, such that 
each corresponding variable pair has the same type. In the sequel, we let £As 
denote the application of the mapping £ to the architecture As- 

The property[2discusses the connection between a system S and its extracted 
architecture £As with respect to the Has and K logical properties {(j) and t/j)- 

Property 1 (Correctness of the mapping) Given a system S and its ex¬ 
tracted architecture £As, for some £, we have that V x, h, ti, <2 in- S and 
V X, i, Ti, T 2 in £As, where {x ^ X, U ^ i, ti 1 —>■ Ti, t 2 >—t T 2 } G £ 

: 1. S G V{Hasfix)) iff £As G S^Hnsf {X)); 2. S G V{Hasf°'^%x)) iff 
£As G S{Has^°^ffX)); and 3. S G V{Ki^ = ^ 2 )) iff £As G 5(a/(Ti = T 2 )). 

The first point of Property says that if the system S satisfies Has^f (x), 
then the extracted architecture £As of S satisfies Hasf^ (X), and vice versa. 
The second point is related to the privacy requirement capturing that when £As 
satisfies Has^°^^{X), the system S satisfies Hasf °^^ (x), and vice versa. The 
third point is related to the integrity property stating that if in the system S 
component h knows ti = t 2 , then in the extracted architecture this component 
knows the corresponding Ti = T 2 , and vice versa. The proof is based on the 
semantics of the architecture and the state based semantics of the systems, as 
well as the correspondence between the deduction rules of the privacy logic and 
the equational theory E of the calculus. 

We give two conformance definitions between protocol and architecture, a 
strong one and a weak one. 

Definition 3 {Strong Conformance) Let us consider a system S and an ar¬ 
chitecture A. We say that S strongly conforms to A up to £ {S A) if 3 £ such 
that £As = A. 


In the strong case, we require that there exists a mapping £ such that £As 
contains exactly the same relations as A. 

Definition 4 ( Weak Conformance) Let us consider a system S and an ar¬ 
chitecture A. We say that S weakly conforms to A up to £ {denoted S \=^ A) if 
(i.) 3 £ such that A C £As: and (ii.) M x, X such that {a; !->■ X} G £: If A G 
S then S G V{Hasl°'^^ (cc)). 

Point (i.) of the weak case requires the more relaxed A C £As- Point (ii.) 
says that for every X in the privacy requirement Hasf°'^^{X) of the architecture, 
Ij cannot have any value t for x in the system S (where {x i—>■ X} G £). 

Next, we provide the state simulation and bisimulation definitions in order 
to formulate Properties and about the relationship between the states of a 
system and states of an architecture in case of weak and strong conformance. 

Definition 5 {State simulation): Let us consider a system S and an archi¬ 
tecture A. We say that A G V(S') simulates a G 5(Al) up to £ (denoted by A Qs 
a), ify li, X, ti, t 2 in S, and\/ i, X, Ti, T 2 in A, such that {U i-G i, x i-G X, t 
I—> T, I—>■ Ti, ^2 T 2 } G £'■ 

- if 3 a[{cj([V/X], af) / a,] G 5(Al), then3 X[{Xl U {t/x}, Aff) / A/J G V(5) 

- if 3 a[{a([eval{T,a()/X], af U {X = T}) / a,] G 5(aI), then 3 A[(AJ1 U 
{X(_t/x}, Xf^ U {x = t}) / Xi-] G V(5'), and 

- if 3 cr[{a(, erf'" U {Ti = T 2 }) / Oi] G 5(aI), then 3 A[(A)'., Af'^ U {h = 12 } 
) / AiJ G V(5). 

Also, we write X cr if X simulates a up to £, but with respect to only the 

pair {X, x), where {x 1 —>■ X} G £. 

Each point of Definition [^captures the state simulation that results from the 
corresponding architecture relations. For example, the second point says that if 
3 Computei{X = T) G A then 3 Computei^{X = T) G £As- 

Definition 6 {State bisimulation): Given a system S and an architecture A: 

1. We say that X G V{S) and a G 5(Al) simulate each other up to £ (A a), 
*/ A Cf a and a A. 

2. We say that X G V{S) and a G 5(Al) simulate each other up to £ and the 

variable pair {X, x), X a, if X a and a A. 

Property 2 Given a system S and an architecture A, where X G V(S') and 
a G S{A). We have that S A iff X c:is o'. 

Property 1^ says that when S strongly conforms to A, then the states of Ij in 
S simulates the states of the corresponding component j in A, and vice versa. 

Property 3 Given a system S and an architecture A, where X G V(S') and 
(T G S{A). We have that S {=£ A iff {i.) X Qg a and {ii.) X a, for all 

X in Haslf°^%X). 


Property says that in case S weakly conforms to A, then the states of 
Ij simulates the states of the corresponding component j, and these states are 
bisimilar for all the variable pair {x, X), such that Has™"^{X) holds. A conse¬ 
quence of Properties and is that it is sufficient to show the state simulation 
and bisimulation to prove the weak and strong conformance properties. These 
two properties also capture the correctness of the mapping with respect to the 
weak and strong conformance definitions. The proof of Properties and is 
based on the defined extraction rules and the correspondence between functions 
Se of the architecture and Vl of the system. 

Example Conformance Check: We check the conformance between an 
example protocol and the architecture Ai at the end of Section]^ with r = 1. 
Let us consider the protocol description in which there are components Im and 
lo that refer to the meter and operator, respectively. The behavior of the meter 
is specified by the process Rm- The operator is defined by the process Rq- 


Rm iet Xci = ki in Pi, 

dc. f 

P2 = let Xsig = sign{xmijSkm) 'In P3; 
Pq — ejjioi^^mi: ^sig) ■ 0 - 


P3 — eYno{^mn ^ sig} ■ 0 - 

3"= I lRo\\^ 


Due to lack of space, we use this very simple example to demonstrate the 
mapping procedure and the conformance check between S and Ai- The initial 
relations set is {Trusti^jj^}. The architecture relations corresponding to S 
can be extracted in the following steps: From the two reductions 


has(lM » Xci :^i) 


ap{lM, 


Cl ) 


lP 2 \i^ I L^oJ/" and rules 


Rhas^ j^comp _ ^init (j ^ {x c^)} U {Computei^{Xmi = Xc,)}- 

The Zef-process in P 2 has no effect on the extraction, while the channel synchro¬ 
nization will result in adding Receiveii^j^{{xmi = a^ci}, Xmi) to as- Since Rq 
terminates right after receiving the attestation, the two Computei^ relations and 
Veriff^*^‘‘*{Attestij^{{xmi = a^ci})) cannot be extracted. This means that the 
system S does not conform to the architecture Ai- 


5 Related Works 

Dedicated languages have been proposed to specify privacy properties (e.g., [3, 
m, [S]) but they are complex and not intended to be used at the architectural 
level. In m the authors addressed the idea of applying formal methods to 
architecture design and proposed a simple privacy architecture language (PAL). 

On the other hand, there are also many works focusing mainly on the protocol 
level, providing formal methods for specifying and verifying protocols, as well as 
reasoning about the security and privacy properties (e.g., m, m, 0). For this 
purpose, process algebra languages are the most favoured means in the literature, 
because they are general frameworks to model concurrent systems. 

In addition, among the process algebras, the applied 7r-calculus m, csi) is 
one of the most promising language in the sense that its syntax and semantics 


are more expressive than the others (e.g., HO], n, m)- It also have been used 
to analyse security and privacy protocols (e.g., in m, CO], m, CHI. i, a, 
m)- However, we cannot use it directly for our purpose because for instance, 
it lacks syntax and semantics for modelling component IDs and trust relations. 
Some modifications and extensions of the applied 7r-calculus are required, which 
we proposed in Section 

Finally, the definition of the architecture comes before the definition of the 
protocol in software development cycles. Therefore, we chose to make it pos¬ 
sible to verify the conformance of a protocol described in our language to an 
architecture. We used the architecture language in for this purpose. Its main 
advantage is that (i) compared to informal pictorial methods, or semi-formal 
representations such as UML diagrams, it is more formal and precise, while (ii) 
compared to process calculi, it is more abstracted. The architecture language 
PAL enables designers to reason at the level of architectures, providing ways to 
express properties without entering into the details of specific protocols. 


6 Conclusions and Future Works 

In this paper, we proposed the application of formal methods to privacy by 
design. We provided the mapping from the protocol level to the architecture level 
for checking if a given implementation conforms to an architecture and showed 
its correctness. For this purpose, we modified the applied 7r-calculus and defined 
the connection between the semantics of the calculus and PAL. To the best of 
our knowledge, this is the first attempt at examining the connection between 
the protocol and the architecture levels in the privacy protection context. 

The calculus version and the mapping procedure we proposed in this paper 
are based on a simplified version of the architecture language. Indeed, we only 
consider the attestation on equation X = T. Moreover, our proposed calculus 
(and mapping) does not support the modelling of zero-knowledge proofs, as well 
as the posibility of spot-checks used in toll pricing systems. Hence, our method 
can only handle simple architectures and protocols at this stage. One future 
direction of our work is to extend the calculus to support these such extensions. 
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